一.骨骼动画系统——基础和原理

二.骨骼动画系统——UE4动画蓝图的使用和图元基础及原理

三.骨骼动画系统——骨骼动画组件数据更新

四.骨骼动画系统——骨骼动画底层数据刷新分析

五.骨骼动画系统——UE4动画压缩技术介绍

六.骨骼动画系统——UE4构建移动技能动画框架&复杂状态机构建

七.骨骼动画系统——UE4动画优化分析

八.骨骼动画系统——捏脸方案的实现与介绍

九.骨骼动画系统——MotionMatch的实现与原理

十.骨骼动画系统——高阶动画应用技术（镜像，AnimWarping，StepWarpping,motionmatch，惯性融合等）

当前正处于元宇宙的风口，各大互联网厂商争相布局元宇宙，一枝独秀的比如超级QQ秀，从该项目中我们可以管窥元宇宙的雏形，人物可定制化，场景可定制化，然后结合社交和养成玩法在游戏中可以做真实世界里边的事情；对于时间充足的人来说，该游戏还是相当有趣的。本文主要来分析元宇宙中角色定制部分捏脸相关的实现方案；笔者从18年开始做捏脸，从unity做到Unreal，调研过不少方案，目前我们的捏脸方案已经推广到多个项目使用，不知道QQ秀是否也用到了？下边我们从多个方面来分析捏脸的技术原理和应用。

传统捏脸方案介绍:

捏脸的核心其实就是骨骼变形，骨骼变形相对比较容易，以Unity来说，选中某个关键骨骼的Transform，设置对应的Pos Rot和Scale就可以实现了骨骼变形，核心问题的当你修改了某个节点的导致骨骼变形以后，在该模型上播放原有的动画可能会导致穿帮或者严重错误的动画表现。所有其实捏脸的核心是表情动画，而不是简单的骨骼变形。所以在以前游戏厂商对技术投入还不是很多的时候，有的厂商使用了美术制作的方式来实现捏脸，该种方式不太需要程序的参与，将所有控制面部表情的骨骼都拆分为2根，一根单独控制表情动画(子)，另一根单独控制捏脸数据(父)，再此基础上进行动画计算后就能保证捏脸的表情动画可以正常。不过该种方式局限性太大了，骨骼双份，不仅美术制作成本高，而且运行效率成本也变高。因此选择一般的捏脸方案都是程序来实现捏脸，主要包含两大方案骨骼捏脸和Morph捏脸。

如何实现简单的捏脸？

以该图为例，我们的捏脸可以精确的控制每一个部位如鼻子的大小，位置和相对朝向。在整个捏脸系统中我们可以控制几十个部位的变换，以数据结构来说我们将有一堆包含了骨骼名称和骨骼的相对Transform偏移信息来实现捏脸。因此整个捏脸系统其实非常简单，就是通过系统界面的滑动条来指定每一根骨骼的骨骼偏移的信息。然后捏脸系统只是将一系列的功能组织起来。目前在虚幻4引擎中最方便使用的方案当然是Morph()方案。

Morph捏脸(blendshape)：

Morph方案是现在使用越来越广泛和频繁的方案，这得易于引擎的完善性和手机性能的提高，UE引擎中完整的支持了整套Morph方案，因此美术设计师只需要在美术软件里边制作好相应的模型定义好各个捏脸部位的骨骼和权重，直接导入引擎即可，引擎里边使用系统界面滑动条直接对Morph系数进行控制，就可以实现了最简单的捏脸效果，Morph是直接控制了Mesh顶点，因此和骨骼动画完全不冲突，但是一般一个模型可能几十根骨骼但是顶点数量却可能有几千个，因此注定了Morph计算量肯定比骨骼控制计算量大一些。以下是Morph相关的原理分析，由于Morph直接控制的是顶点变形，因此导入的数据就是包含了每帧的顶点信息，这些信息在UE里边主要是封装在其LOD数据结构下，其主要逻辑在GPUSKin完成，将相应的顶点数据直接传递到GPU参与运算。但是由于Mesh和骨骼动画又是深入绑定的，因此一般是在骨骼动画矩阵更新完成后再更新Morph数据。Morph的参数导入UE引擎后是一系列的序列帧，Morph动画就是动态的控制这部分序列帧。

Morph实现捏脸如此的简单，为什么还有很多游戏使用的骨骼捏脸呢？这是历史原因，传统的手机性能并不怎么好，在大规模使用上，骨骼控制的性能要明显优于Morph顶点控制。因此还是有大量游戏使用骨骼进行捏脸，甚至有一些方案是骨骼捏脸结合Morph方案，根据各自的需求单独定制方案，而且这样的趋势越演越烈。简单来说可以分以下方案:

1.骨骼捏脸+骨骼表情

2.Morph捏脸+Morph表情

3.骨骼捏脸+Morph表情

4.Morph捏脸+骨骼表情

5.(Morph+骨骼)捏脸+骨骼表情等等多种组合方案。

方案有很多种，能实现游戏需求的方案也有很多种，不过我们往往要针对项目的实际情况来选择最适合自己项目的方案。

如何快速实现捏脸的骨骼变形？

morph方案可以导入即用，但是骨骼方案的实现却没有那么简单，一般说来需要程序去实现一部分。最简单的的骨骼变形是是UE提供了一个蓝图图元叫ModifyBoneTransform组件，该组件可以动态修改模型的某一根骨骼的Transform信息，来实现一根骨骼的捏脸功能。因此从该功能入手，我们就可以推导出2中骨骼捏脸的实现方案：

方法1：基于ModifyBoneTransform组件，在动画蓝图里边连上几十个节点，每个节点控制一个骨骼，那么就可以控制脸部几十根骨骼的变换，快速实现一个简易捏脸方案。真是简单易行。

方法2：基于ModifyBoneTransform组件，扩展该组件，使之可以支持控制几十个骨骼同时进行Transform转换变换，该种方式需要程序扩展，其实也是一种简单易行的方法，据说网易的某个项目就是采用的该方案。该种方式还是蛮值得推荐的，总的来说该种方式优势明显，也有一部分少量的弊端，主要是美术使用层面上和游戏中非捏脸时刻的运行效率问题。不管是否在捏脸界面该蓝图其实一直在参与计算，虽然是动画线程但是其计算量还是蛮大的。

骨骼捏脸：

从以上可以得知，其实骨骼捏脸的根本原理就是要改变一部分骨骼的变换矩阵，捏脸系统中控制的面部部位可能就几个比如眼睛鼻子嘴巴耳朵等等，但是实际脸部骨骼的数量可能有几十甚至上百根，而且控制每个部位的捏脸系数可能控制了不同的骨骼且权重都不太一样，因此这一系列的关系都要在捏脸系统里边实现组装起来。骨骼捏脸最根本的目标是批量修改骨骼，从第三四章中：郭袁：骨骼动画系统——骨骼动画组件数据更新(三)郭袁：骨骼动画系统——骨骼动画底层数据刷新分析(四) 我们分析了骨骼骨骼的生命周期，骨骼矩阵会先经过动画图元处理，然后回到主线程进行数据转换，再进行交换可读可写矩阵，最终再将可读矩阵提供给渲染线程使用。从整个生命周期我们可知，方法1和2是在动画图元阶段修改骨骼矩阵，但是实际情况只要骨骼矩阵还没有提交渲染，你可以再任何步骤自定义修改他的数据。因此我们采用了完全自定义的独立捏脸模块+完全自定义的捏脸骨骼矩阵后期修改方法，在提交渲染矩阵前的任意一步修改其动画矩阵即可。

骨骼动画和骨骼捏脸都是一种控制骨骼变换的情况，这里需要关注先后顺序，是先捏脸再叠加播放动画矩阵还是先播放动画矩阵再叠加捏脸矩阵？笔者在老版本的Unity5.6实现捏脸的时候在Update函数里边实现了捏脸控制逻辑，然后播放动画的时候总是会出现莫名其妙的错误，之后分析了Unity的动画数据读写流程，才知道Unity的动画数据回写在Update之后，因此将复写骨骼数据矩阵的顺序搞错了会导致功能完全错误，后不得不将捏脸的主要控制逻辑全部放在LateUpdate里边去执行。在Unity里边：

每帧步骤：Update ()-> FillAnimationData ->LateUpdate();

将捏脸的功能控制放在LateUpdate后看起来没有什么太大问题了，该函数主要是骨骼控制逻辑，但是后期随着复杂度的提高，也就是头和身体如果完美衔接我们还是出现了问题，主要原因是LateUpdate里边的控制逻辑已经是动画数据完全解读完了，但是有一部分逻辑需要在动画矩阵之前运算(其余大部分是在动画矩阵之后运算)，因为某些特殊的节点需要先预设，设置好之后再经过动画矩阵处理，才能完全正常，这个主要问题表现在脖子接缝问题。后续会为脖子接缝问题单独细讲。

捏脸方案：

简单的实现捏脸功能后，更重要的是将脸组装起来，首先要考虑的是是捏脸功能的模块化，不和任何其他模块有衔接，方便移植；然后是捏脸数据的模块化，只需要通过数据来还原和保存捏脸，可以方便的进行捏脸网络同步，也可以很方便拷贝应用其他人的捏脸，另外还要考虑数据压缩，捏脸数据尽可能的小。捏脸方案除了包括骨骼捏脸以外，可能还会包括妆容贴花等等，一般眼睛鼻子嘴巴耳朵都是采用骨骼捏脸，像胡子眉毛和眼瞳等等采用贴花的方式去实现，换个简单的贴图或者颜色参数就能变出不同的妆容，但是也有的3A游戏的胡子和眉毛是采用模型做的，也就是说要通过换胡子和眉毛的模型来实现捏脸定制。这就给捏脸系统带来了一定的复杂度，因为挂上去的胡子眉毛是独立的模型，理论上他应该和脸的表情动画表现完全一致，但是如果胡子眉毛单独播放动画的话，除了性能问题你也没办法保证2个动画完全的帧数同步，一定会出现穿帮的情况。

Unreal提供了一个很方便的解决方案，叫PoseableMeshComponent组件，郭袁：骨骼动画系统——骨骼动画组件数据更新(三)；该组件可以很方便的拷贝其他Mesh的骨骼动画数据，让所有的附带模型可以和主模型播放相同的动画且保证不穿帮。该种方式实现快捷，简单易行，另外还有一种更好的方法是采用MasterPose共享骨骼的方式，至于采取哪种方案很大程度跟模型的制作方式和骨骼的使用方式等等很多细节相关联。

捏脸妆容&换装：

捏脸妆容和换装一般都是通过切换材质贴图，颜色参数和换模型来实现，一般情况下都使用基于相同骨骼的部件，可以切换人物身上的任意部件，和游戏中的avatar系统类似。一般采用AlphaBlend叠加一些不同的效果，具体的表现一般看没事需求，可以做到非常复杂。

LookAt:

游戏中常有一些交互性的视觉表现，比如天刀里边，当玩家靠近某个人的时候 那个人会主动注视主角，或者在捏脸界面当选中角色后，人物也会盯着摄像头看，带来较强的交互体验感。Lookat的基本原理就是控制一堆骨骼从脖子到头骨骼到眼睛骨骼旋转指向到某个Pos，每个层级的骨骼的旋转幅度和权重都不一样，最终带来较为合理的Lookat体验。一般情况下在lookat驱动转动开启，过程中和结束点都有不同的参数，来达到较好的效果。比如我们转头的时候会先简单转动头部到某个视觉位置，转动结束后并不是马上停止，而是会有小幅度的头部位移延迟和眼睛轻微抖动效果等等。较好的Lookat就是用不同的阶段和参数模拟不同的动画效果。

接缝处理：

在处理头部模型和身体模型的时候，经常会出现脖子接缝这样的问题，有的游戏采用的是将头和身体骨骼模型做在一块，这种做法当然不会出现该问题，但倘若头的骨骼数量很大就不得不分开制作了。接缝分多种问题，常规的比如模型接缝，动画接缝，贴图和光照接缝等等。模型接缝问题一般就是需要根据美术制作的规则将正确的节点挂在正确的父骨骼上，若挂错了就会出现不匹配的接缝了。解决该问题就可以谈到了我们的多骨骼挂点组件。UE默认提供的挂点组件只能挂在父模型的单根骨骼上，但是美术为了某些表现可能需要子模型多个骨骼挂在父模型的多个骨骼上，因此我们开发了该组件可以方便美术可以任意数量骨骼作为挂点。但是一般情况下的脖子接缝是由于制作不规范导致的，父子骨骼规范就可以避免Mesh接缝问题，贴图精度一致就可以解决光照导致的脖子颜色接缝等问题，同时还要处理脖子处的切线和法线吻合。

触摸识别:

触摸识别就是通过手指触摸屏幕直接驱动面部骨骼进行捏脸，而不是简单使用UI滑动套进行捏脸，该功能可以带来更多的互动感。这个方法唯一的难点是我们如何选中指定骨骼呢？因为选中骨骼后我们其实根据屏幕滑动的delta就可以控制参数，选中指定部位也有多种实现方式，其实最简单的一种就是在每根骨骼上绑一个碰撞体通过屏幕射线和碰撞体通道来告知当前选中了哪块脸部骨骼，这种方式美术制作稍微麻烦一点。另一种方式采用屏幕像素渲染的方式，将每个部位的渲染颜色值单独使用一个通道进行渲染，渲染到指定RT后，从GPU拷回CPU，然后在CPU上查询该渲染目标的像素值，就知道了我们当前选中哪个部位了，该种方式为了性能可能将渲染RT调到极小。

捏脸和表情穿帮问题：

捏脸和表情动画原则上都是可以无限制的控制每根骨骼的Transform，如果毫无节制，自然会出现一些骨骼过度扭曲导致Mesh变形等问题，该种问题一般情况下美术在制作的时候就制定好每根骨骼的最小最大的波动范围，而不是仍由其自由发挥，制定好规范以后一般情况下就不会穿帮了。但是有的情况下 单纯的捏脸和动画都不会穿帮，但是捏脸后播放表情动画就会穿帮，这是怎么回事呢？一般情况下可能是规范没定好，也有可能是算法流程有一定问题，常规最好的验证或者解决方案就是将捏脸骨骼和表情骨骼分块制作分开控制，该种方式就可以轻松实现捏脸和解决穿帮问题。但是如果算法能解决的话最好还是用算法流程解决，要计算好骨骼动画和捏脸的先后关系。

眨眼融合：

在解决了捏脸表情的融合后，发现眼睛还是可能会出现无法闭住的融合问题，我们开发了眨眼融合算法就实现，我们的算法主要是通过映射关系去计算骨骼融合。另外还有一种实现和制作方式是通过blendshape的方式实现融合，该种算法主要参考《腾讯游戏开发精粹2》第8章，他们的方案介绍了在他们的制作方式下的闭眼融合流程。

捏脸Blend：

在一些卡通或非写实游戏里边常常会有捏脸融合的表现，简单来说就是会制作多张脸，比如人，兽，神，然后通过简单的滑动盘在三张捏脸中渐变，可以达到玩家只需要简单的操作可以捏出复杂的变换效果，而不是滑动条一根根的捏，通常可能会捏出个废材。该种方式的实现方式一般是结合了骨骼捏脸和Morph捏脸来实现的，同时还有考虑贴图Blend的融合。渲染公式其实比较简单：但是实现细节比较复杂。

SSDR：

刚性骨骼平滑蒙皮分解算法Smooth Skinning Decomposition with Rigid Bones（SSDR）。可以通过该算法将Morph动画通过AI分解解算得到骨骼动画，该种方式可以在美术测使用Morph制作动画，表现效果高，然后通过算法将骨骼解算出来，通过播放骨骼动画来达到较好的动画效果，不过该种方式也受限于骨骼的数量来表现。一般肯定是骨骼数量越大还原度越高，该算法GitHub上有开源库可用。https://github.com/electronicarts/dem-bones SSDR模型可以通过较少的刚性骨骼和稀疏、凸的骨骼顶点权重映射，有效地逼近近关节模型和高度可变形模型的皮肤变形。将SSDR模型描述为一个约束优化问题，在LBS法重建顶点的最小平方误差最小的情况下，采用基于块坐标下降的算法迭代更新权值图和骨骼变换。通过在权值图上引入稀疏性和凸性约束，SSDR模型可用于传统的蒙皮分解任务，如动画压缩和硬件加速渲染。此外，通过对骨骼旋转矩阵（刚性骨骼）施加正交约束，SSDR模型还可以应用于运动编辑、骨骼提取和碰撞检测任务。通过定性和定量的评估，我们表明SSDR模型在精度和适用性方面优于最先进的皮肤分解方案。

捏身体

在一些卡通游戏里边通常会有捏身体，比如肥胖，高矮等等，但是写实游戏里边一般不会有。是因为捏身体可以带来更多的外观变动，同时也会带来更多的不确定性，因此捏身体只适合一些卡通MMO类游戏。捏身体的原理和捏脸没有什么区别，但是要解决的问题会更多。比如身体高低胖瘦变化以后人物的衣服裤子如何保证同比缩放和适配？武器和武器挂点是否还合理？相应的动画是否还合理？一些动画在不同高矮下可以通过retarget适配，但是如果要做高细腻度的3A动画，可能会发现就算retarget后动画还是会有轻微失真 达不到高保真效果。不过这些问题都可以通过一些特定的方案去解决，但是成本性可能需要考虑一下。

照片捏脸&捏脸的口型动画：

根据照片自动捏脸和根据语言数据自动生成口型动画，都是近几年AI的游戏领域的前沿应用，而且很多项目已经实践使用过效果也还可以。照片AI捏脸市面上也有多种方案，通常是设立一个深度神经网络，其输入层是读入照片生成的点阵模型，输出层为若干个人脸特征参数的数值。然后拟合训练，最后将人脸特征参数数值映射为人脸模型所绑定的骨骼变动数值，完成智能捏脸。 参考《腾讯游戏开发精粹2》的第一章。

口型自动生成同样也有多种方案，目前应用较广泛的是 FACS全称面部动作编码系统，通过面部编码的方式将语音编码转换到面部表情编码。在影视行业CG制作中常使用；原理是根据人类面部动作肌肉特点，将面部动作进行拆分，得到46个动作单元（即AU）。而音素是最小的语音单位，一个发音动作构成一个音素；对汉语拼音来说，一个字母对应一个音素，但是存在一些特例，比如两个字母表示一个音素（zh、ch、sh、ng、er），变形音素（iu-iou，un-uen）等。

不同的捏脸骨架如何共享动画？

不同的骨架进行动画匹配，通常我们想到的就是ReTarget方案，该种方式在一些身体动画上可以还原90%效果，但是细节的动画还是会失真。但是面部骨骼想要共享表情动画，细腻度非常的重要，一点失真都会让表情陷入僵硬。因此我们开发了基于动画烘焙还原骨骼控制器的方案。

要解决不同骨骼动画的完全还原，除了算法的调整还有美术工作流的调整，其中一种方式是采用控制器去实现动画，不同骨架采用不同的控制器参数，但是动画参数一致，从而可以实现完美适配。

从DDC软件将相应的控制器参数导出到引擎进行参与计算，该种方式对程序算法和美术制作都还是有一定的考验的。

另外我们采用了基于动画烘焙的方式来烘焙出控制器参数，该种方式将所有压力放在了程序算法上，但是可以减少很多美术工作流程，目前该种方式表现还是不错的。